home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 380 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.8 KB
  1. Subject: Re: Fast serial (was: misc kernel patches... (mostly tty stuff))
  2. Date: Fri, 16 Jul 93 21:06:48 CES
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <9307152225.AA02020@terminator.rs.itd.umich.edu>; from "Nicholas S Castellano" at Jul 15, 93 6:25 pm
  5. Message-Id: <9307161906.AA00231@jelal.north.de>
  6.  
  7. Nicholas S Castellano writes:
  8.  
  9. > > ok!  but that still requires changes in MiNT.  for example currently it
  10. > >seems a 1K tty read gets _always_ translated into 1000 device reads of
  11. > >each one char, that just cant be fast no matter how good the driver is...
  12. > >and to get it real fast such a driver would also need a way to tell
  13. > >MiNT that it reads and writes bytes, not longs.  then it could get a
  14. > >RAW 1K read or write as that and just bcopy the data. (and also sleep
  15. > >gracefully when it waits for more than a few bytes to go over the port
  16. > >so it doesn't have to waste so much CPU time...)
  17. > 
  18. > The idea would be to have the drive bypass MiNT completely and twiddle
  19. > the iorec itself, to do the reads and writes.
  20.  
  21.  well thats exactly what i hacked into uucp...  i thought you were
  22. talking about a driver to install as replacement for /dev/{modem,serial}*,
  23. the problem is when you do that and tell MiNT that its a tty (O_TTY,
  24. is_terminal), MiNT will do these things for you... (please correct me
  25. if i'm wrong.)
  26.  
  27.  or do you mean a something like /dev/modem1raw, i.e. a device not marked
  28. as tty that can then only be used for RAW?  i don't think that would
  29. help because programs usually don't expect to have to open a different
  30. device for RAW...
  31. > 
  32. > The only thing at all difficult about doing this that i've noticed is
  33. > that the iorec elements seem to be misnamed and misdocumented; in
  34. > practice the head element seems to really be the tail and vice-versa.
  35.  
  36.  true :-)  (actually its not too easy because you have to think a little
  37. to avoid race conditions and such... but its certainly possible.)
  38. > 
  39. > > or things like TIOCCAR/CLOCAL, HUPCL.. they probably need some help
  40. > >from the kernel too.
  41. > 
  42. > I don't know what those are, but they look like maybe part of the
  43. > system V tty driver controls?
  44.  
  45.  yup... CLOCAL is termio(s) (local mode, turn on to chat with the modem,
  46. then turn off and you get SIGHUP when carrier goes away...)  TIOC(N)CAR
  47. is the same for BSD (i think :-)  HUPCL is `hang up on close' (drop DTR
  48. when the device gets close()d), also known as TIOCHPCL.
  49.  
  50.  another useful thing would be VMIN (min. number of characters to read,
  51. only known in termio), then you don't have to calculate times to sleep
  52. when you need to read at least n characters in RAW mode...
  53.  
  54. >  Of course if you want to support new
  55. > driver controls at least some of them will need to be in the kernel.
  56.  
  57.  ok :)
  58. > 
  59. > >>  I've been thinking recently
  60. > >> that most of my TOS 1.0 hacks in MiNT's rsconf() code should really be
  61. > >> in a standalone device driver as well (especially since that code
  62. > >> still doesn't work terribly well.)
  63. > >
  64. > > well either this, or just forget about those 1001 TOS bugs and tell
  65. > >people to use one of the serial port fix TSRs available, some of them
  66. > >now even work. :)
  67. > 
  68. > I agree, but I never found one that corrected the TOS 1.0 bug of not
  69. > being able to query the port speed.  (I think I found one that claimed
  70. > to do this but actually just caused spectacular crashes.) 
  71.  
  72.  hmm..  well since TOS 1.04 it just remembers the last speed set with
  73. Rsconf, if someone changes the timer settings themselves you still get
  74. wrong results.  (have you tried hsmodem1?)
  75. > 
  76. > > and for a standalone modem driver rsconf (and iorec) would better just
  77. > >translate their parameters into device ioctls, right?
  78. > 
  79. > For the most part yes, but they could also do nice things like giving
  80. > real FIONREAD/FIONWRITE results for the serial port, allow Fselect()
  81. > on the port, etc.
  82.  
  83.  well this both then can be fixed in the driver i would say...
  84.  
  85. > No, I was talking about a MiNT installed device for fast/better serial
  86. > port access, not a TSR.  I could go dig through my old mail and find
  87. > the refernce but it would probably be faster to just write the code
  88. > :-).
  89.  
  90.  oh :-)
  91. > 
  92. > > other than that i only know of someone who seems to hate MiNT so much
  93. > >that he wrote a fast driver that tries to act like MiNT, but for TOS!
  94. > >(looks for Fopen ("u:\dev\modem1"..) and then handles Fread/Fwrite
  95. > >itself or so...  i guess if you could read all those maus news you'd
  96. > >sometimes just shake your head... :-)
  97. > 
  98. > I love it when people say they hate MiNT so they want to implement all
  99. > its functionality in TOS (e.g. they are effectively saying they want
  100. > to write their own MiNT :-)
  101.  
  102.  no need to tell me, tell that Harun_Scheutzow@b.maus.de :-)
  103.  
  104.  cheers
  105.     Juergen
  106. -- 
  107. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  108.                                 ...ohne Gewehr
  109. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  110.